This document describes various types of E-mail connectivity for systems that have dial-up connections to the global network.
UUCP Links
There are several types of dial-up links (i.e. links that use modems and regular phone lines). A very popular link type is uucp (named after the Unix-to-Unix Copy Program). The uucp protocol was designed in the mid-70's to transfer files between two Unix systems over phone lines. Later, a uucp-based E-mail system was designed. For many years, it was the only type of E-mail available via dial-up links.
The uucp mail is based on the "store and forward" algorithm, i.e. each computer sends the entire message to its "neighbor" via phone lines, and that neighbor then transfers it to its neighbor, and so on till the message is delivered to the recipient computer.
Limitations of the UUCP protocol
While very effective for batch mail transfers, uucp links have one major disadvantage: those links support mail transfer only, and Internet services such as Web, FTP, Telnet are not available over these links.
Internet and SMTP
In the 1980's, the Internet network became more and more popular. All machines on the Internet had permanent links to the global network. The Internet network allowed each machine to send small packages of data to some other machine. In spite of the fact that the packets could pass several "relays", it looked like each machine could establish a "communication link" to any other machine on the Internet at any time. An E-mail system was designed for Internet. That system was called SMTP - Simple Mail Transfer Protocol.
The SMTP mail system uses the DNS (Domain Name System) to convert the domain part of an E-mail address to the network address of that computer, establishes a communication link with the SMTP server software on that machine and transfers the message directly to the recipient machine. Messages are transferred without being stored on intermediate hosts.
When more machines appeared on the Internet, it was realized that some of them might not be available immediately. So, the MX records were introduced in the DNS. The MX records can specify several computers for any given E-mail domain. If the computer with the highest MX-record priority cannot be reached, other computers are contacted. As a result, if a message cannot be delivered directly to the recipient computer, it is sent to a computer that is "very close" to the recipient. That computer then tries to contact the recipient to transfer the message.
Limitations of the SMTP protocol.
The SMTP protocol works perfectly for computers that have permanent Internet connections and that are available almost always. But it was not designed for the systems that connect to Internet from time to time (as dial-up systems described below).
Dial-up Internet Links
In the 1990's, it became possible to access the global TCP/IP network (Internet) over regular phone lines using a modem and a PPP (Point-to-Point Protocol) software. The PPP software dialed, connected the provider host modems and started to transfer IP packets over the modem link. As the Internet booms these days, 90% of computers, especially personal computers use the PPP (or the older SLIP) protocol to connect to Internet. The big advantage of the PPP links over uucp links is the ability to run various applications (E-mail, World Wide Web, FTP, Telnet, etc.) over one link: when a connection is established, all Internet services become available. As a result, it is not a problem to send mail over dial-up links: the same SMTP software can be used to contact any host on the Internet and to send E-mail messages. The major problem is receiving mail.
Dial-up IP problem #1:
Most of the Internet Service Providers (ISPs) give their clients dynamic IP addresses, i.e. each time a dial-up system connects to the provider host, it gets a network address selected from the pool the provider possesses. It makes it impossible to give those systems domain names and to register them with the Domain Name System, since no network address can be associated with them.
Dial-up IP problem #2:
Even when a fixed IP address is assigned to a dial-up system, that system is not connected to the Internet 24 hours a day, so the SMTP protocol cannot deliver mail when the system is off-line. Usually, SMTP systems retry to send messages every 30 minutes, so in order to get its mail, a computer on a dial-up link should stay on-line for at least half an hour.
The POP protocol
The problems described above made it impossible to assign domain names to computers that had dial-up links to the Internet. As a solution, providers started to give each dial-up system an account on their own host. Since provider machines have permanent link to Internet, there is no problem to send mail to those accounts. The POP (Post Office Protocol) was introduced to allow dial-up systems to retrieve mail from their accounts on the provider host. Many of the E-mail programs that used POP protocol to retrieve mail appeared. On personal computers, the Eudora application by Steve Dorner became the most popular one.
Limitations of the POP-based solutions
The scheme described above is perfect for personal computers that need only one E-mail account.
• If several accounts are needed, they have to be created on the provider host (usually, for more money).
• Since all clients have accounts on the provider host machine and the provider host name as the domain part of their E-mail addresses, no two clients can have the same "info" or "sales" accounts.
• Clients cannot have their own domain names. Sometimes, providers register domain names for their clients, but they simply map them on their own domain. I.e. the "client1.com" and the "client2.com" domains are processed as the "provider.com" domain. It allows one client to have an E-mail address that looks like "sales@client1.com", but in this case the second client cannot have the "sales@client2.com" account - both accounts are mapped to the same "sales" account on the provider host (provider.com).
Note: this problem is solved in the CommuniGate Server: when used as a provider host, it can map the sales@client1.com account into the "sales.client1" account, the sales@client2.com account into the "sales.client2" account, etc.
Unified Domain-Wide POP accounts
In order to solve the problems listed above, so-called "domain-wide" accounts were introduced in 1995. Now providers can register domain names for their clients and configure the provider mail software to store ALL mail that comes to the client domain name in one account. In other words, the provider mail software ignores the "user name" (also called the "local part") of incoming E-mail addresses, and all messages sent to "john@client1.com", "bill@client1.com", "sales@client1.com" are stored in one "client1" account on the provider host, while messages sent to "john@client2.com", "bill@client2.com", "sales@client2.com" are stored in the "client2" account.
Note: Unified domain-wide accounts are supported with most Unix mail servers and the CommuniGate Server.
While the problems of creating new accounts, intersection of E-mail addresses, and assigning own domain names are solved with the domain-wide accounts, a proper software is needed to retrieve mail from those accounts. When the first domain-wide accounts appeared, the regular POP-based mailers as Eudora were used to retrieve mail (since the POP protocol itself did not change). As a result, all messages sent to various users of the dial-up system ended up in one In Box of the mailer software, and then the messages were sorted manually and transferred to the recipients via file sharing.
With the introduction of the CommuniGate POPGate 1.4 in late 1995, it became possible to use unified domain-wide POP accounts automatically: the POPGate downloads each message from that account, parses its headers, and routes the message to the proper account on the local CommuniGate system. This solution gives the dial-up POP-based mail system the same power and flexibility as that of an SMTP-based system permanently connected to the Internet.
Limitations of the Unified Domain-wide account
The provider has to support this service, and the dial-up system should have mail software that can parse and route incoming messages.
SMTP-based System on Dial-up Links
While domain-wide POP accounts provide the service equal to that of SMTP-based systems, it is impossible to use it if the provider cannot support it. In 1995-1996 several new methods were introduced. These methods allow to use SMTP systems for mail receiving. As explained above, the main problem is retry intervals: while a dial-up system is off-line, messages sent to it are postponed, and the system has to stay on-line long enough to get all those messages when sending systems retry.
First of all, MX records in DNS are used to make all mail go to the provider host when a dial-up system is off-line. Then, some methods are used to "wake up" the provider queue, so it starts to send mail immediately when the dial-up system establishes a link.
The first method is called "Wake-up E-mail": when a dial-up system establishes a link, it sends a dummy E-mail message to a special account on the provider host. When a message is received, a special "daemon" on the provider machine releases all postponed messages, and they are sent to the dial-up system immediately.
The second method became the standard in August 1996 (RFC1985) and it is called "Remote Queue Starting": a dial-up system connects to the provider SMTP server as when it needs to send mail, and then it issues a special "wakeup" command. When the provider system receives that command, it releases the message queue.
Note: The CommuniGate SMTPGate supports the RFC1985 in the server mode, and it supports both "wake-up E-mail" and RFC1985 in the dial-up client mode. These days, the only other program supporting the dial-up SMTP receiving is Window NT mail server, which is in the alpha-testing stage.
Limitations of the Remote Queue Starting SMTP systems
Both the provider and the dial-up system have to support this service with their mail software.
